home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0136.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  2.9 KB  |  62 lines
  1. Certificate management quite possibly could be put under the domain of
  2. IMSP.  I don't have a good understanding of how to do it, so until
  3. someone gives me a well-designed proposal, it's not going to happen.
  4.  
  5. On the other hand, it could be that certificate management belongs in
  6. the directory service.  So far I have tried to keep directory service
  7. functionality out of IMSP for the simple reason that directory
  8. services open up entire cans of worms.
  9.  
  10. My current preferences encryption are for protocol extensions to the
  11. IMAP and IMSP protocols to cause the entire data stream to be
  12. encrypted.  If you're concerned about privacy, you really want this in
  13. IMAP in order to keep network snoops from reading your mail while you
  14. do.  If, for performance reasons, you want only pieces of critical
  15. data to be encrypted, you can pop into and out of encrypted mode at
  16. appropriate times.
  17.  
  18. If one wants authenticated delivery of mail, but is unwilling to pay
  19. the cost of an end-to-end scheme like PEM, there are two obvious
  20. approaches: One approach is to add authentication to an existing
  21. delivery service, another is to add delivery service to an existing
  22. authenticated protocol.
  23.  
  24. I agree with Mark that the first approach is far superior.  A delivery
  25. system that has an authentication mechanism can use it to preserve the
  26. authentication during intermediary delivery hops.
  27.  
  28. Adding delivery service to an existing authenticated protocol (such as
  29. IMAP) requires that the implementation learn all sorts of things
  30. regarding delivery: envelope addresses, authenticated message
  31. transport, and the like.  In order to do it correctly, the
  32. implementation has duplicate everything in the delivery service.
  33.  
  34. As Mark points out, the first approach has better fallback
  35. characteristics for when authenticated delivery is not supported.  If
  36. a client takes the first approach but the delivery system does not
  37. support authentication, then the mail is delivered anyway--it is just
  38. not authentic.  If a client takes the second approach and the existing
  39. authentication protocol does not support delivery, then the client
  40. either has to support a second delivery mechanism or it will not be
  41. able to deliver the mail.
  42.  
  43. Internet protocol devopment is geared toward making small, simple
  44. services, which try to do few things, but do them well.  They
  45. presuppose the use of an underlying transport system that handles the
  46. mundane tasks of providing multiple, reliable connections.
  47.  
  48. Failure to keep protocols simple and focused on apropriate tasks leads
  49. to over-complex, unwieldy systems.  If IMAP has to support message
  50. delivery for situations where the client does not have a transport
  51. mechanism which can support multiple connections, does it not also
  52. have to support other mail-related services, such as user information
  53. (Finger), directory service (X.500), password-changing, etc?
  54.  
  55. -- 
  56. _.John G. Myers        Internet: jgm+@CMU.EDU
  57.             LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
  58.  
  59.  
  60.  
  61.  
  62.